Subject: Support of Frame-Relay RFC1490 SNA Encapsulation

From: "Steve Klein" <[email-masked]>
Date: Thu, 22 Jun 95 10:05:36 EDT

Jim, my opinions on the subject are imbedded below.  This is my personal
opinion and does not reflect any official IBM position on the subject.

>One purpose of industry bodies such as the AIW and the Frame-Relay Forum is
>to agree on critical aspects for interoperability.  With regards to the
>encapsulation of SNA over Frame-Relay IBM has presented to the
>Frame-Relay Forum and the AIW a recommendation written by Rao Cherukuri.
>This recommendation is certainly not intended to be an exhaustive list of
>the possible encapsulations for SNA, but it was obviously intended as a
>minimum common middle ground which all vendors can agree on.  This
>encapsulation was referenced explicitly in the HPR reference.
>
>A problem which a number of people have commented on in this regard is the
>lack of product support for this proposal.  This may reflect fundamental
>inadequacies in the recommendation.  That is products are not implementing
>this recommendation because it does not satisfy the needs of real
>customers.  In particular there are existing products which transport SNA
>using the 802.5 bridging format, for example BAN or RXR/2.  There are other
>products which transport SNA by first encapsulating it inside TCP/IP, for
>example the 6611.

I think the routed SNA formats in FRF.3 are ideal for communication
between SNA NNs, ENs, and LENs.  The problem that we tried to solve
with BAN was the interconnection of subarea LAN nodes to NCP through
non-APPN routers.  We felt that introduction of another way to do
'SNA over Frame Relay' was worth it when weighed against the increased
ease of administration that BAN allows.

>We are not exactly overjoyed at the prospect of having to implement and
>validate three different encapsulations of SNA just in order to be certain
>of being able to communicate with all of the products out there.
>
>Should the AIW consider abandoning the existing recommendation and focussing
>on the more flexible 802.5 ("bigGER, not BIG") and IP encapsulations?  Or
>should we be more insistent that the recommended format is base
>functionality, and therefore products which use another format exclusively
>are not compliant to the architecture?

Why should there only be one format?  All three have there place:
  - FRF.3: Native attachment of NNs, ENs, and LENs.
  - BAN:   Interconnection of subarea SNA nodes through non-APPN routers.
  - IP encap: Transport of SNA over IP backbones.

Regards, Steve

---

From: David Matusow <[email-masked]>
Date: Thu, 22 Jun 1995 13:04:54 -42000

> ease of administration that BAN allows.

there is no reason that FRF3.1 can't be used by non-APPN routers.  This 
has been done by several vendors.  creating the distinction for subarea 
LAN nodes going through BAN is not interesting.

>   - IP encap: Transport of SNA over IP backbones.
yes, they all three have their place in the market.  FRF3 has much lower 
overhead than the others and from this point of view is superior.  It 
also provides ALMOST all of the functions and configurations.

BAN has migration purposes for some configurations.  It makes life easier 
for the vendor and reduces some configuration requirements.

IP encapsulation is great if you have an IP network with few SNA 
devices.  As a means to support generalized SNA connectivity...well, the 
marketplace has already had extensive discussion about such items as 
session timeouts and other nasty outgrowths.

I don't think there is one way that is "correct" (I also think this is 
what Steve was saying).  We need some alternatives to drive ourselves and 
our customers crazy.  Isn't that the purpose of all of this?

David